home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19941221-19950208 / 000294_news@columbia.edu_Fri Jan 27 14:38:51 1995.msg < prev    next >
Internet Message Format  |  2020-01-01  |  3KB
  1. Received: from apakabar.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA10318
  2.   (5.65c+CU/IDA-1.4.4/HLK for <kermit.misc@watsun.cc.columbia.edu>); Fri, 27 Jan 1995 09:38:59 -0500
  3. Received: by apakabar.cc.columbia.edu id AA00667
  4.   (5.65c+CU/IDA-1.4.4/HLK for kermit.misc@watsun); Fri, 27 Jan 1995 09:38:57 -0500
  5. Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
  6. From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
  7. Newsgroups: comp.protocols.kermit.misc
  8. Subject: Re: File Transfers Fail Uploading but not Downloading!
  9. Date: 27 Jan 1995 14:38:51 GMT
  10. Organization: Columbia University
  11. Lines: 46
  12. Message-Id: <3gb0hr$ki@apakabar.cc.columbia.edu>
  13. References: <D31EGK.Mo3@physics.purdue.edu>
  14. Nntp-Posting-Host: watsun.cc.columbia.edu
  15. Apparently-To: kermit.misc@watsun.cc.columbia.edu
  16.  
  17. In article <D31EGK.Mo3@physics.purdue.edu>,
  18. Andrew J. Korty <korty@london.physics.purdue.edu> wrote:
  19. >The problem is this: I can download beautifully (9K packets at 1850
  20. >CPS on a 19200 device with no harware compression), but when I try to
  21. >upload, I can only send a few packets.  When the file is small (under
  22. >about 3 packets), I get amazing transfer rates, as high as 7500 CPS!!!
  23. >
  24. >I'm using C-Kermit for OS/2 on my PC and C-Kermit on the remote host
  25. >also.  I've tried this with MS-Kermit on this end under both DOS and
  26. >OS/2 (with MS-Kermit the problem is even worse; can send absolutely no
  27. >more than one packet), and I've tried uploading to different remote
  28. >machines with different C-Kermit edits.  Therefore, I think the
  29. >problem must be my DOV (data-over-voice) unit.  If you're not familiar
  30. >with these, they are Hayes compatible modems that allow you to connect
  31. >and talk on the phone at the same time.  It's a direct connection to
  32. >the remote dialup server.
  33. >
  34. Data connections are rarely symmetrical.  The fact that something works
  35. in one direction is not a good predictor of success in the other
  36. direction.
  37.  
  38. Yours are the classic symptoms of big buffers in the downstream direction,
  39. tiny buffers in the upstream direction.  A common configuration, based on
  40. the assumption that when one makes a dialup connection, the only upstream
  41. traffic will be keystrokes (at most, 10 per second), but the downstream
  42. traffic will be voluminous (the responses to your commands).
  43.  
  44. Where are these "buffers"?  Probably in the terminal server.  And in your
  45. case maybe we also have something going on with the modems.  Maybe your
  46. DOV modems allocate higher bandwidth upstream than down.
  47.  
  48. To cope with this situation, you can sometimes reconfigure the
  49. communications equipment to be more symmetrical.  This requires digging
  50. through the technical manuals for the devices involved.
  51.  
  52. But in any case, it is ESSENTIAL to institute the most effective possible
  53. means of flow control at EVERY juncture along the communication path:
  54. between your PC and the modem, between the answering modem and the
  55. terminal server, and so on.  This should be "hardware" (RTS/CTS) flow
  56. control if it is available.  In-band "software" flow control methods such
  57. as Xon/Xoff do not work nearly as well.  Unfortunately RTS/CTS is not
  58. always available.  For example, one popular terminal server model supports
  59. RTS/CTS only in one direction (the downloading one, on the aforementioned
  60. assumption) so uploads through these devices often run into trouble.
  61.  
  62. - Frank